Challenge delegation moved the ACME challenge out of the served domain's
zone, but left three records behind that the operator still had to create
by hand, and two reasons to come back to them.

The accounturi CAA needs a second visit: the container can compute it but
not write it, and it names an ACME account that does not exist until the
first issuance has succeeded.

The app-address TXT carries the app id, which by default is the hash of
app-compose.json and so moves when the compose does -- add an environment
variable and the gateway stops routing until someone updates the record.
It can be pinned with `vmm-cli deploy --app-id`, which is how an app is
upgraded in place, so this is avoidable rather than inevitable. But it is
the default, and it fails silently: the certificate keeps renewing, only
traffic stops.

Alias all three names into the delegation zone instead. The operator
creates three CNAMEs before deploying and is then done, permanently:

    svc.example.com                      CNAME  svc.example.com.deleg.net
    _dstack-app-address.svc.example.com  CNAME  _dstack-app-address.svc.example.com.deleg.net
    _acme-challenge.svc.example.com      CNAME  _acme-challenge.svc.example.com.deleg.net

The container publishes what they point at, including the CAA.

The gateway pointer and the CAA end up on one name, which RFC 1034 does
not allow -- a CNAME excludes every other type at its name. Cloudflare
allows the pair anyway and Let's Encrypt honours the CAA it finds there,
verified against the staging CA: a CAA that forbids the CA stops issuance
with `While processing CAA for svc.example.com: CAA record for
svc.example.com prevents issuance`. The resolver stops at the first name
in the chain carrying a CAA rather than following to the end, so a CAA at
the delegation zone apex is *not* consulted -- also verified.

Providers that enforce the standard reject the pair, so the record type
follows the provider: Cloudflare gets a CNAME and keeps DNS following a
gateway that moves; everything else gets an address record, which can
carry the CAA legally, at the cost of re-resolving GATEWAY_DOMAIN once a
pass. Only Cloudflare has been tested, so only Cloudflare gets the
optimistic default; DELEGATION_GATEWAY_RECORD overrides either way.

The variable is now DELEGATION_ZONE. ACME_CHALLENGE_ALIAS was accurate
when the challenge was the only thing delegated and is not any more; it
is removed rather than deprecated, since the feature is days old and the
published image does not carry it.

Renewal passes verify only the challenge alias. The other two are about
serving, and dns-01 never connects here, so blocking a renewal on them
would turn a routing problem into an expired certificate. The first pass
checks all three, because that is setup.

The delegated challenge's propagation wait also had to go from 30s to
120s: it must outlast the record's own 60s TTL, or the second of the two
issuance attempts fails Let's Encrypt's multi-perspective check with
"During secondary validation: Incorrect TXT record found".

Publishing the CAA from inside the container made a chain of things dead
without anything failing, which is how they survived. A review found:

- delegation_verify_caa, and with it the only caller of ALLOW_MISSING_CAA
  and of dnsguide's --caa-required / --caa-advisory. Wildcards were the
  last user; once the container published their CAA too, the whole path
  was unreachable. The README still advertised ALLOW_MISSING_CAA.

- check_caa's require_present parameter and its three tests. The
  semantics it existed for -- "an absent CAA must block, because we
  cannot create it" -- stopped being true when we started creating it.
  Absence now just means "not published yet", and the next pass fixes it.

- Two test classes defined twice over. Python shadows the earlier
  definition silently, unittest counts the later one, and the total still
  goes up, so duplicated blocks look like passing tests. A guard now
  walks the file's AST and fails on any repeated class or method name;
  it was checked against a deliberately duplicated block.

- Stale naming: --challenge-alias and args.challenge_alias outlived the
  variable rename, and ACME_CHALLENGE_PROPAGATION_SECONDS with them. Both
  now say delegation. The README still claimed ACME_CHALLENGE_ALIAS
  "still works", which had not been true since it was removed.

Also reject contradictory --include values. `delegated` is a shape rather
than a record kind -- it replaces the per-kind records instead of adding
to them -- so `--include cname,delegated` would emit two CNAMEs claiming
the same name. Unknown values are now rejected too, instead of being
silently ignored.